Current goals for the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) program are to bring new technology, new architecture and new methods to new LTE settings and configurations in order to provide improved spectral efficiency and reduced latency for better utilization of radio resources for faster user experiences and richer applications and services with less cost.
As part of this evolution process, the 3GPP group will use different security architectures in LTE than used in Universal Mobile Telephone System (UMTS) and Global System for Mobile Communications (GSM) systems. For the sake of comparison, let the UMTS Authentication and Key Agreement (AKA) procedures, in packet switched (PS) domain, be the baseline for the proposed new LTE procedures.
FIG. 1 shows a UMTS access stratum protocol stack 100. The UMTS AKA and ciphering procedures are spread over multiple protocol layers and use both non-access stratum (NAS) and radio resource control (RRC) signaling to accomplish their goals. Generally, identification and authentication of the wireless transmit receive unit (WTRU) is accomplished via NAS signaling. Once authentication at a NAS level is accomplished, ciphering and/or integrity protection is activated by the network using the Security Mode Command which is a RRC message. Once security is activated using the Security Mode Command at the RRC layer, the WTRU passes the ciphering and integrity keys (CK and IK) to the access stratum (AS) using the GMMAS-SECURITY-RES primitive over the GMMAS-SAP (defined between GPRS Mobility Management (GMM) and the AS). After receiving these keys, the RRC 110 passes them to the radio link controller (RLC) 120 and medium access control (MAC) 130 using the CRLC-CONFIG primitive (over the C-SAP between the RRC and RLC) and the CMAC-CONFIG primitive (over the C-SAP between the RRC and MAC). The C-SAP (not shown) is a Service Access Point for C-plane signaling between the RRC and lower layers. The actual ciphering and integrity protection is usually performed in the RLC 120, but is performed in the MAC 130 in case of transparent RLC mode traffic. The lower layers (i.e. MAC/RLC) are responsible for ensuring that messages intended for upper layers (e.g. Layer 3 NAS messages) have been integrity protected and/or ciphered correctly. If not, the lower layers ignore/drop the message. Once security has been activated all C-plane and U-plane security is done in the RLC or MAC.
For LTE, a radically different architecture for security has been proposed. The main difference is that instead of a single security layer (i.e. in the MAC/RLC) there are three layers of security: NAS security, RRC security and U-plane security. Each layer has its own keys. NAS security terminates in the mobility management entity (MME) and is performed in the NAS layer. RRC security terminates in the evolved node B (e-NB) and is performed in the Packet Data Convergence Protocol (PDCP). U-plane security consists of ciphering only (no integrity protection) and is also performed in the PDCP. In brief, the AKA procedures are completed in the NAS and NAS security keys are derived. The RRC/U-plane security parameters are derived in a cryptographically separate manner from the NAS keys. Knowledge of the RRC/U-plane keys does not allow an attacker to determine the NAS keys. The main rationale for this decision was that in LTE one might have e-NBs in vulnerable locations, such as in a home. RRC, and therefore security, is terminated in the e-NB, so this was considered to be a security risk. Hence two levels of security were adopted for the standard.
FIG. 2 is a block diagram of key hierarchy in LTE 200. As shown in FIG. 2, the USIM (in the wireless transmit/receive unit (WTRU)) and the Authentication Centre (AuC) 205 share a secret K 210. As part of a NAS Authentication and Key Agreement (AKA) signaling (similar to current UMTS AKA procedures) the USIM and the AuC/HSS derive a Ciphering Key (CK) 215 and an Integrity Key (IK) 220. The procedure for deriving the CK 215 and IK 220 are similar to that in UMTS where the AuC/HSS derives an Authentication Vector and sends a challenge to the WTRU in a NAS message which the WTRU responds to and the HSS/AuC verifies. Unlike UMTS however where the CK 215 and IK 220 are provided to the MAC/RLC layers to perform ciphering and/or integrity protection, in LTE the CK 215 and IK 220 are used to derive the remaining keys in the key hierarchy beginning with a master key—the so-called KASME key 225. The remaining keys are derived from the KASME key using different key derivation functions (KDF) and truncating.
KeNB 230 is a key derived by WTRU and MME from KASME 225 or by WTRU and target eNB from KeNB* during eNB handover. The KeNB 230 is used for the derivation of keys for RRC traffic and the derivation of keys for UP traffic or to derive a transition key KeNB* during an eNB handover.
KNASint 235 is a key that is used for the integrity protection of NAS signaling with a particular integrity algorithm. This key is derived by WTRU and MME 237 from KASME 225, as well as an identifier for the integrity algorithm using a KDF.
KNASenc 240 is a key that is used for ciphering NAS signaling with a particular encryption algorithm. This key is derived by WTRU and MME 237 from KASME 225, as well as an identifier for the encryption algorithm using a KDF.
KUPenc 245 is a key that is used for ciphering UP traffic with a particular encryption algorithm. This key is derived by WTRU and eNB 247 from KeNB 230, as well as an identifier for the encryption algorithm using a KDF.
KRRCint 250 is a key that is used for integrity protection of RRC traffic with a particular integrity algorithm. KRRCint 250 is derived by WTRU and eNB 247 from KeNB 230, as well as an identifier for the integrity algorithm using a KDF.
KRRCenc 255 is a key that is used for ciphering RRC signaling with a particular encryption algorithm. KRRCenc 255 is derived by WTRU and eNB 247 from KeNB 230 as well as an identifier for the encryption algorithm using a KDF.
The RRC and U-plane keys may be derived with the C-RNTI as an input.
In existing UTRAN security architecture, a check for correct ciphering and/or integrity protection is done in the RLC or MAC. The only security failure handling scenario currently in the NAS is if authentication fails. However with a separate ciphering and integrity protection procedure in the NAS, it would be desirable to define NAS procedures in response to scenarios in which a NAS message is received without being correctly ciphered and/or integrity protected.
The NAS relies on the AS, that is, the RLC or MAC, to verify that any Layer-3 (L3) messages received have the correct security credentials, that is, were ciphered and integrity protected properly. Since the new LTE architecture which has NAS layer security independent from AS security and the NAS verifies the security of L3 messages, this approach is inadequate because the checking of NAS security is done as part of procedures defined in NAS behavior. Thus it would be desirable for actions for the NAS to be defined in case of failure.
Since the NAS keys are independent of the RRC/U-plane keys (hereinafter, AS keys) it is possible to start/re-configure NAS ciphering independently of AS ciphering/integrity protection. It would be desirable to have new messages and procedures for this process. Also, key expiration may be linked to the NAS/RRC state of the WTRU. It would be desirable to have procedures for WTRU key handling.
The RRC typically receives the new CK and IK from the NAS and passes them to the MAC and RLC where ciphering/integrity protection is performed. However, in LTE, AS ciphering and integrity protection will be performed by the PDCP. Thus, it would be desirable to have new cross-layer procedures and primitives for proper security functioning.